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EXECUTIVE  SUMMARY 


This  report  documents  the  results  of  a  controller  design  review  of  the  proposed 
functionality  and  computer-human  interface  for  Controller-Pilot  Data  Link 
Communications  Build  I  (CPDLC-I)  planned  for  implementation  on  the  Display 
System  Replacement  (DSR). 

Thirteen  Air  Traffic  Control  Specialists  and  Supervisors  participated  in  the 
review.  Organizations  represented  by  the  participants  included  the  Air  Traffic 
Data  Link  Validation  Team  (ATDLVT),  the  DSR  Design  Team,  the  Minneapolis 
Air  Route  Traffic  Control  Center  (ARTCC),  and  the  National  Air  Traffic 
Controllers  Association  (NATCA).  As  preparation  for  the  design  review,  the 
controllers  received  2  days  of  classroom  training  sessions  and  hands-on  air  traffic 
control  (ATC)  simulation  experiences  designed  to  familiarize  them  with  CPDLC- 
I,  the  DSR  workstation,  and  the  proposed  CPDLC-I  controller  interface  for  DSR. 
Each  controller  then  completed  a  structured,  independent  review  of  the  CPDLC-I 
functionality  and  interface  design.  Finally,  the  controllers  participated  in  a  group 
debriefing. 

The  design  review  exercise  produced  data  on  controller  preferences  for 
assignment  of  DSR  Category  Keys  to  CPDLC-I  functions  and  generated  findings 
which  indicate  that  modifications  are  needed  to  the  proposed  CPDLC-I  display, 
control  and  service  designs.  Key  results  included:  (1)  a  requirement  for  three 
Category  Keys  to  support  single  keystroke  access  to  both  the  Transfer  of 
Communication  (TOC)  and  Predefined  Message  services,  and  to  adjust  Data  Link 
Settings,  (2)  a  need  to  modify  the  Initial  Contact  (IQ  service  design  to  permit  the 
aircraft  altitude  report  to  be  compared  to  an  adapted  altitude  as  well  as  an 
assigned  or  interim  altitude  previously  entered  by  the  controller,  and  (3)  a 
requirement  to  add  the  “no  response”  message  type  to  the  proposed  set  of  pilot 
response  options.  The  participants  also  generated  12  additional 
recommendations  for  modifications  to  the  computer-human  interface  to  enhance 
controller  performance,  reduce  errors,  and  increase  the  acceptability  of  the 
system. 
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1. 


INTRODUCTION. 


1.1  BACKGROUND. 

The  Federal  Aviation  Administration  (FAA)  intends  to  field  an 
International  Civil  Aviation  Organization  (ICAO)-compliant,  En  Route 
Controller-Pilot  Data  Link  Communications  (CPDLC)  capability  in  the 
National  Airspace  System  (NAS)  by  2003.  In  its  final  form,  CPDLC  will 
provide  controllers  with  the  ability  to  uplink  a  variety  of  clearance  and 
advisory  messages  to  equipped  aircraft,  and  aircrews  will  be  able  to 
downlink  reports  and  Air  Traffic  Control  (ATQ  requests. 

As  a  step  toward  achieving  this  goal,  the  FAA  is  planning  a  12-  to  18-month 
field  test  of  CPDLC  to  validate  some  of  its  potential  benefits,  serve  as  a 
proof  of  concept,  and  generate  data  to  assist  in  the  development  of  the  end- 
state  system.  The  field  test  will  be  conducted  at  the  Minneapolis  Air  Route 
Traffic  Control  Center  (ARTCC)  and  will  provide  a  subset  of  the  end-state 
en  route  CPDLC  messages  known  as  CPDLC  Build  I  (CPDLC-I). 

CPDLC-I  will  offer  a  capability  for  controllers  to  send  the  transfer  of 
communication  (TOC)  message  using  Data  Link,  and  for  pilots  to  respond 
to  the  TOC  by  accepting  or  rejecting  the  message.  As  part  of  the 
acceptance  reply,  pilots  may  downlink  an  initial  contact  (IC)  message 
containing  the  aircraft’s  assigned  altitude  as  they  enter  a  new  en  route 
sector.  Upon  receipt  of  the  IC,  the  ATC  system  will  automatically  verify  the 
altitude  and  alert  the  new  controller  if  it  fails  to  match  the  assigned  altitude 
(or  interim  altitude)  stored  in  the  NAS  database.  CPDLC-I  also  will 
provide  a  capability  to  send  altimeter  setting  messages  (ASM)  to  aircraft 
and  to  uplink  predefined  messages  (PDM)  containing  nonsafety  critical 
information. 

The  CPDLC-I  messages  will  be  transmitted  to  properly  equipped  aircraft 
via  an  existing  very  high  frequency  (VHF)  Data  Link  network  supplied  by  a 
commercial  air-ground  communications  service  provider.  Associated  Data 
Link  aircrew  interfaces  and  avionics  currently  installed  on  the  flight  decks 
of  many  commercial  transport  aircraft  will  be  used  to  support  the  airborne 
portion  of  the  system.  On  the  ground,  CPDLC-I  will  be  supported  by  the 
Host  Computer  System  and  the  Data  Link  Applications  Processor. 

CPDLC-I  functionality  will  be  integrated  with  the  display  and  input  devices 
of  the  Display  System  Replacement  (DSR)  controller  workstation  that  will 
be  operational  at  the  Minneapolis  ARTCC  prior  to  the  field  test. 

The  Operational  Test  (OT)  of  CPDLC-I  will  be  conducted  at  the  FAA 
William  J.  Hughes  Technical  Center  in  advance  of  the  field 
implementation.  As  a  part  of  the  OT  effort,  Minneapolis  ARTCC 
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in  high  fidelity  ATC  simulation  scenarios  to  evaluate  the  operational 
effectiveness,  suitability,  and  acceptability  of  CPDLC-I. 

L2  CPDLC-I  IMPLEMENTATION  ISSUES. 

The  FAA  Technical  Center  has  conducted  high  fidelity  simulation  research 
on  ATC  Data  Link  communications  for  the  past  10  years.  This  research 
has  produced  an  en  route  controller  interface  for  CPDLC  and  related 
procedures  that  support  effective  controller  performance  and  minimize 
controller  workload.  In  addition,  these  studies  have  shown  that  availability 
of  the  full  en  route  CPDLC  message  set  will  significantly  reduce  voice  radio 
frequency  congestion,  and  that  CPDLC  can  increase  controller 
effectiveness  and  produce  tangible  benefits  to  NAS  users. 

Differences  between  the  CPDLC  system  and  message  set  used  in  the 
studies  cited  above  and  the  limited  message  set  provided  by  CPDLC-I 
suggest  that  only  a  small  subset  of  the  conclusions  and  benefits  from  the 
simulation  research  may  be  applicable  to  CPDLC-I.  Efforts  to  determine 
the  potential  impact  of  some  of  these  differences  will  have  to  await  the  full- 
scale  simulation  capabilities  and  information  that  will  be  available  during 
the  OT  exercise.  For  example,  while  the  performance  characteristics  of 
the  Aeronautical  Telecommunications  Network  (ATN)  were  assumed 
during  original  CPDLC  development,  CPDLC-I  will  use  the  commercial 
provider’s  VHF  Data  Link  network.  The  speed  and  reliability  of  this 
network  for  delivering  ATC  messages  will  be  determined  during  the 
technical  portion  of  OT,  and  these  performance  characteristics  will  be 
replicated  during  controller-in-the-loop  simulations  designed  to  assess 
operational  suitability  and  effectiveness. 

Other  differences  between  the  CPDLC  system  tested  in  simulation 
research  and  CPDLC-I  can  be  initially  addressed  prior  to  the  OT  effort. 

The  computer-human  interface  (CHI)  for  CPDLC  was  developed  and  tested 
on  the  Plan  View  Display  (PVD)  that  is  currently  operational  in  ARTCCs. 
CPDLC-I  will  use  the  new  DSR  workstation.  Physical  display  and  control 
differences  between  the  PVD  and  DSR  systems,  as  well  as  display  software 
differences  may  require  that  the  CHI  for  CPDLC-I  be  somewhat  different 
than  the  one  used  during  previous  CPDLC  simulations.  In  addition,  the 
proposed  functionality  for  the  services  included  in  CPDLC-I  differs  from 
that  developed  and  tested  in  earlier  research.  For  these  reasons,  user  input 
is  needed  to  ensure  that  the  transition  of  Data  Link  messaging  capabilities 
to  the  DSR  platform  maintains  the  advantages  of  the  system  developed  on 
the  PVD  platform  during  CPDLC  simulation  activities. 
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2. 


OBJECTIVE. 


The  objective  of  the  design  review  exercise  documented  in  this  report  was 
to  identify  functional  and  CHI  control  and  display  options  that  are 
operationally  suitable  and  acceptable  to  controllers  for  implementing 
CPDLC-I  capabilities  on  the  DSR.  Hands-on  simulation  exercises,  visual 
aids,  and  system  design  descriptions  were  used  to  provide  participating 
controllers  with  an  understanding  of  CPDLC-I  functionality  and  the 
proposed  CPDLC-I  CHI  for  DSR.  The  structured  expert  inputs  of  these 
controllers  were  used  as  a  basis  for  recommending  preferred  design 
options  and  any  modifications  to  the  CPDLC-I  that  may  be  needed  prior  to 
OT. 

3.  TEST  CONDUCT. 

3.1  TEST  PARTICIPANTS. 

The  participants  in  this  study  were  13  en  route  air  traffic  control  specialists 
and  supervisors.  Five  of  the  controllers  were  individuals  who  possess 
subject  matter  expertise  on  ATC  Data  Link  communications.  Four  of  these 
were  the  en  route  members  of  the  Air  Traffic  Data  Link  Validation  Team 
(ATDLVT).  The  ATDLVT  was  established  to  provide  user  input  during  the 
development  of  the  full  CPDLC  message  set  and  PVD  CHI  design.  Each  of 
the  controllers  assigned  to  the  team  participated  extensively  in  the  design 
process  and  has  many  hours  of  experience  in  using  CPDLC  during  high 
fidelity  simulation  studies.  The  fifth  controller  with  Data  Link  expertise 
was  the  National  Air  Traffic  Controller  Association  (NATCA) 
representative  for  Data  Link. 

Four  additional  controllers  were  drawn  from  an  air  traffic  team  that  is 
participating  in  the  DSR  development  process.  One  of  the  controllers  was 
the  NATCA  representative  to  the  team.  These  controllers  are  familiar  with 
the  DSR  CHI  and  associated  input  and  display  conventions. 

Three  controllers  were  from  the  Minneapolis  ARTCC  where  the 
operational  implementation  of  CPDLC-I  will  occur  for  the  field  test.  The 
final  participant  was  the  NATCA  representative  who  will  participate  in  the 
development  and  evaluation  of  CPDLC-I  training. 

Informed  consent  to  participate  in  the  exercise  was  obtained  from  each 
participant  upon  arrival  at  the  FAA  Technical  Center.  The  consent  form  is 
contained  in  appendix  A  of  this  document. 
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3.2  TEST  FACILITIES. 


The  exercise  was  conducted  at  the  FAA  Technical  Center.  Conference 
facilities  were  used  for  test  participant  briefings,  presentations  on  CHI 
design  options,  and  debriefing  discussions.  FAA  simulation  laboratories 
located  at  the  Technical  Center  were  used  for  demonstrations,  hands-on 
exercises,  and  CHI  design  review  activities. 

The  NAS  en  route  laboratory  houses  the  Host  Computer  System  and  PVD 
controller  workstations  that  are  used  to  display  radar  and  system  data  and 
to  enter  system  inputs.  The  laboratory  appearance  is  identical  to  an 
operational  en  route  control  area  and  includes  a  full  voice  communications 
system.  The  participants  in  this  study  controlled  traffic  in  the  NAS 
laboratory  in  order  to  gain/refresh  their  knowledge  of  the  CHI  originally 
developed  for  CPDLC.  Low  to  moderate  traffic  ATC  scenarios  were 
presented  to  the  controllers  under  the  Host  dynamic  simulation  (DYSIM) 
training  mode.  The  DYSIM  mode  permits  a  pseudopilot  stationed  at  a  PVD 
to  enter  inputs  that  control  displayed  aircraft  in  response  to  controller 
communications.  A  Sun  Workstation  emulated  the  future  ground  Data 
Link  processor  and  supported  all  digital  communications  between  the 
participating  controllers  and  pseudopilots.  Software  originally  written  to 
develop  and  test  the  full  CPDLC  message  set  on  the  Host/PVD  system  was 
used  to  provide  Data  Link  functionality  during  the  CHI  familiarization 
activity. 

The  DSR  laboratory  was  for  hands-on  examination  and  manipulation  of 
the  DSR  CHI.  No  CPDLC-I  functionality  was  implemented  on  the  DSR  for 
this  study.  However,  the  DSR  displays  and  input  devices  were  fully 
functional  and  the  system  permitted  interactive  simulation  using  all  other 
en  route  NAS  commands. 

3.3  TEST  PROCEDURES. 

The  exercise  was  conducted  over  a  period  of  3  days.  Upon  arrival  at  the 
test  site,  the  participants  received  an  overview  briefing  describing  the 
objective  of  the  study,  the  activities  that  would  be  conducted,  and  their 
responsibilities  in  the  review  of  the  CPDLC-I  CHI  for  DSR.  Following  this 
overview,  the  controllers  were  asked  to  read  and  sign  the  informed  consent 
document  required  for  participation  in  the  study  (see  appendix  A). 

3.3.1  PVD  CPDLC  CHI  Familiarization. 

Activities  began  with  a  1-hour  classroom  training  session  to  familiarize  the 
controllers  with  Data  Link  CHI  originally  developed  for  the  Host/PVD 
system.  The  purpose  of  this  training  was  to  provide  the  controllers  with 
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knowledge  of  the  PVD  inputs  and  displays  that  would  act  as  a  baseline  for 
evaluating  the  proposed  CPDLC-I  service  designs  for  the  DSR.  The 
training  covered  all  CPDLC  messages,  but  emphasized  those  functions 
included  in  CPDLC-I. 

The  classroom  session  was  followed  by  two,  2-hour  practice  periods  in  the 
Host/P VD  NAS  laboratory.  A  one-half  hour  discussion  session  was 
conducted  between  the  practice  periods  to  answer  any  open  questions 
about  the  CPDLC  CHI  and  the  rationale  that  guided  its  design. 

Controllers  were  assigned  to  the  radar  and  data  positions  for  the  practice 
exercise.  ATC  scenarios  derived  from  Atlanta  ARTCC  airspace  were  used 
to  permit  the  controllers  to  interact  with  the  simulated  aircraft  using  Data 
Link.  Facilitators  were  available  to  assist  the  controllers  with  the  CPDLC 
message  inputs  and  acquaint  them  with  the  airspace  and  traffic  flow  in  the 
simulated  sectors.  The  controllers  were  given  a  checklist  of  CPDLC  tasks 
to  perform  while  controlling  traffic  in  the  scenario.  These  tasks  required 
the  controllers  to  exercise  all  of  the  Data  Link  settings  controls,  send  the 
TOC  message  using  both  the  manual  and  automatic  modes,  observe  the 
Full  Data  Block  (FDB)  displays  of  transaction  status  and  equipage/ 
eligibility,  and  experience  failure  displays  including  “time-out”  and  IC 
altitude  mismatches.  Each  pair  of  controllers  alternated  between  the 
positions  at  their  sector  in  order  to  provide  them  with  experience  in  the 
radar  and  data  CPDLC  inputs. 

3.3.2  DSR  CHI  Introduction  and  Hands-On  Demonstration. 

The  second  day  of  the  study  began  with  a  2-hour  classroom  session  that 
was  used  to  familiarize  the  controllers  with  the  DSR  CHI.  Representatives 
from  the  FAA  Office  of  Air  Traffic  Systems  Development  (AUA)  conducted 
the  training.  Graphic  visual  aids  and  other  briefing  materials  were  used  to 
acquaint  the  controllers  with  the  physical  layout  of  the  DSR  workstation, 
and  to  describe  keyboard  inputs  and  displays.  The  intent  of  the  effort  was 
to  provide  the  participants  with  knowledge  of  the  display  and  input 
conventions  used  in  DSR.  Emphasis  was  placed  on  the  differences 
between  the  PVD  and  DSR  controller  interaction  requirements. 

The  CPDLC-I  CHI  elements  were  not  addressed  during  this  training 
session.  However,  in  order  to  maximize  the  effectiveness  of  the  classroom 
activity,  topics  that  are  closely  associated  with  the  CPDLC-I  CHI  were 
emphasized.  These  included  the  radar  computer  readout  device  (R-CRD), 
the  keyboard  category  keys,  the  R-CRD  category  selection  area,  and  the 
function  keys. 
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Training  was  followed  by  a  2-hour  interactive  practice  session  in  the  DSR 
laboratory.  The  DSR  consoles  were  configured  to  define  contiguous 
airspace  sectors.  Simplified  ATC  scenarios  developed  for  DSR  testing  and 
demonstration  presented  traffic  flows  passing  through  the  three  sectors. 
Controllers  were  assigned  to  the  radar  and  data  positions  at  each  of  the 
sectors  and  rotated  positions  to  permit  all  participants  to  work  with  the 
system. 

Predefined  flight  plans  were  used  in  the  scenarios  and  no  communications 
with  the  simulated  aircraft  were  implemented.  However,  the  controllers 
were  able  to  make  all  DSR  inputs  and  observe  the  results  in  the  FDB 
displays  and  views. 

The  controllers  were  given  a  checklist  of  DSR  tasks  to  perform  while 
controlling  traffic  in  the  scenario.  These  tasks  focused  on  the  elements  of 
the  DSR  CHI  that  will  be  used  to  incorporate  CPDLC-I  functionality.  In 
particular,  the  tasks  required  the  controllers  to:  (1)  examine  the  content 
and  manipulation  of  displays  that  will  be  employed  by  CPDLC-I  or  are 
similar  to  those  that  will  be  developed  for  CPDLC-I;  (2)  observe  the  current 
DSR  keyboard  assignments  of  the  function  and  category  keys;  and  (3) 
perform  the  actions  that  are  required  to  offer  and  accept  hand-offs. 
Facilitators  were  available  to  assist  the  controllers  with  the  DSR  inputs  and 
acquaint  them  with  the  airspace  and  traffic  flow  in  the  simulated  sectors. 

3.3.3  Introduction  to  the  CPDLC-I  CHI  for  DSR. 

After  receiving  training  on  the  DSR  display  and  input  conventions  and 
completing  practice  in  using  the  CHI,  the  controllers  were  introduced  to 
the  proposed  implementation  of  CPDLC-I  on  the  DSR.  A  1-hour  classroom 
training  session  was  conducted  to  present  the  proposed  DSR  keyboard 
inputs  and  displays  associated  with  sending  TOC,  PDM  and  ASM, 
monitoring  Data  Link  transactions  including  IC  errors,  and  adjusting  Data 
Link  settings.  In  addition,  the  presentation  covered  the  available  category 
and  function  key  assignment  options  for  the  Data  Link  and  Data  Link 
Settings  keys  that  are  used  in  composing  a  majority  of  the  CPDLC-I  inputs. 

3.3.4  CPDLC-I  Design  Review. 

The  final  activity  of  the  second  day  of  the  study  was  a  detailed  evaluation 
of  the  CPDLC-I  design.  Each  controller  performed  an  independent 
evaluation  by  completing  the  questionnaire  items  contained  in  a  design 
review  booklet  (see  appendix  B).  The  booklet  structured  the  controller 
evaluations  around  five  primary  topics:  (1)  Data  Link  and  Data  Link 
Settings  Category  Key  assignments,  (2)  Data  Link  FDB  and  Status  list 
Displays,  (3)  TOC  inputs  and  displays,  (4)  IC  displays,  (5)  PDM  inputs  and 
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displays,  and  (6)  ASM  inputs  and  displays.  The  controllers  were  asked  to 
rank  their  preferences  for  each  of  the  available  Data  Link  Category  Key 
design  options  and  to  indicate  any  of  the  options  that  would  be  completely 
unacceptable. 

The  TOC,  PDM,  and  ASM  inputs  and  the  TOC,  PDM,  and  IC  displays  for 
DSR  were  presented  for  individual  evaluation  using  descriptive  text.  In 
each  case,  the  controller  was  asked  to  provide  an  overall  evaluation  of  each 
service  design  and  to  record  any  recommended  or  required  CPDLC-I 
design  modifications  resulting  from  a  conflict  between  the  proposed 
CPDLC-I  design  and  DSR  design  conventions.  They  also  were  asked  to 
indicate  whether  each  of  severed  potential  enhancements  to  the  CPDLC-I 
designs  would  be  desirable  for  future  builds  of  the  system. 

In  order  to  facilitate  the  evaluations,  the  design  review  exercise  was 
conducted  in  the  DSR  laboratory  while  the  controllers  were  seated  at  the 
display  consoles.  This  location  permitted  the  controllers  to  refer  to  the 
DSR  keyboard  layout  and  to  manipulate  the  display  as  needed  to  assist 
them  in  completing  their  evaluation  booklets. 

3,3,5  Structured  Debriefing. 

The  final  day  of  the  study  was  devoted  to  a  structured  group  discussion 
and  debriefing  session.  The  session  was  used  to  perform  an  item-by-item 
review  of  the  controller’s  responses  to  the  design  review  questions  and 
ratings.  The  emphasis  of  the  debriefing  was  to  identify  and  resolve  any 
disagreements  regarding  the  suitability  and  acceptability  of  the  proposed 
CPDLC-I  functionality  and  CHI  design,  and  to  achieve  consensus  regarding 
options  for  the  Data  Link  Category  Key  assignments.  The  group  discussion 
was  documented  in  notes  recorded  by  test  personnel  and  on  an  audiotape 
record  for  reference  during  data  analysis  and  report  preparation. 

4.  RESULTS. 


The  following  findings  are  a  synthesis  of  the  inputs  that  were  obtained 
from  the  independently  written  controller  design  reviews  and  the 
structured  group  debriefing. 

4.1  DSR  CATEGORY  KEY  REQUIREMENTS  FOR  CPDLC-I. 

The  design  of  the  DSR/Host  Computer  System  software  architecture 
permits  the  entry  of  commands  at  the  Radar  position  by  a  two-step 
process.  Pressing  one  of  the  keyboard  Category  Keys  (or  trackball 
selecting  a  key  in  the  R-CRD  Category  selection  area)  gives  the  controller 
access  to  a  group  of  functions  subsumed  under  that  category.  These 
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functions  are  displayed  in  the  R-CRD  view  that  can  then  be  selected  by 
trackball  or  by  pressing  one  of  the  keyboard  Function  keys.  The  first 
function  in  the  group  is  assigned  default  status,  and  need  not  be 
pressed/selected  to  complete  the  command  sequence. 

The  proposed  design  that  was  presented  to  the  controllers  for  review  called 
for  two  category  keys  to  be  assigned  to  CPDLC-I.  One  of  these  was  labeled 
the  Data  Link  category  (DL)  and  would  be  used  to  compose  and  send 
messages.  The  Data  Link  Settings  category  (DS)  would  be  used  to  set  the 
TOC  mode,  the  ASM  mode,  display  a  list  of  current  sector  Data  Link 
settings,  and  to  select  or  modify  the  contents  of  Data  Link  lists.  During  the 
individual  design  review,  each  controller  was  asked  to  indicate  his 
preference  for  rearranging  the  assignments  of  the  six  category  keys  to 
accommodate  these  two  CPDLC-I  categories. 

The  subsequent  structured  debriefing  resulted  in  a  clear  majority  of  the 
participants  adopting  a  proposal  that  was  originally  offered  by  five  of  the 
controllers  in  their  individual  comments.  The  group  indicated  that  a  total  of 
three  category  keys  would  be  required  to  implement  CPDLC-I  in  a  form 
that  will  be  acceptable  to  controllers.  Two  of  the  keys  are  needed  to 
provide  single  keystroke  access  to  the  primary  CPDLC-I  TOC  and  PDM 
services.  These  keys  must  be  represented  in  the  keyboard  Category  Key 
Area  and  in  the  R-CRD  category  selection  area.  The  third  key  is  needed  to 
provide  access  to  the  Data  Link  Settings  function  and  can  be  implemented 
on  the  R-CRD  and  as  a  secondary  function  of  one  of  the  keyboard  category 
keys  accessed  by  depressing  the  “Multifunction”  keyboard  key. 

This  requirement  was  driven  by  the  nature  of  the  Host  controller  interface 
and  software  architecture.  As  discussed  above,  according  to  the  design 
conventions  of  this  architecture  only  one  group  of  functions  can  be 
accessed  by  a  category  key.  Of  the  group,  one  of  the  functions  is  a  default 
choice  (hot  key).  Consequently,  only  the  default  function  can  be  accessed 
by  a  single  keystroke.  The  controllers  indicated  that  the  functions  of 
transmitting  a  “held”  TOC  message  and  selecting  a  PDM  menu  item  must 
both  be  available  with  a  single  input  action.  As  a  result,  two  independent 
keys  will  be  required  for  these  services. 

The  controllers  stated  that  failure  to  provide  this  level  of  access  to  one  of 
the  services  would  seriously  compromise  its  utility  and  would  almost 
certainly  result  in  a  low  level  of  usage  in  the  field. 

Several  options  were  considered  for  positioning  these  keys  in  the  six-key 
Category  Key  area.  Based  on  the  individual  responses  obtained  from  the 
design  review  booklets,  the  preferred  keys  for  use  in  accessing  the  TOC 
category  and  the  (PDM)  category  included  any  of  the  keys  in  the  top  row 
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of  the  area  and  the  first  key  on  the  left  of  the  bottom  row.  Existing 
function  categories  that  the  controllers  indicated  could  be  effectively 
combined  to  free  two  of  the  keys  were  EMER  CHK  /  POS  CHK  and  RSB  / 
RNG  BRG.  In  DSR,  the  subordinate  function  is  selected  on  a  combined 
key  by  pressing  the  MULTI  FUNC  keyboard  key  prior  to  pressing  the 
category  key. 

While  no  final  consensus  on  a  specific  keyboard  layout  was  achieved,  the 
following  arrangement  was  suggested  as  a  preliminary  alternative: 

Keyboard  Category  Keys 


DL  TOC 

/ 

DS 

METER 

LIST 

SIM 

DL 

MENU 

RNG  BRG 
RSB 

POS 

CHK 

R-CRD  Category  Selection  Area 


DLTOC 

METER 

LIST 

SIM 

EMERG 

CHK 

DL 

MENU 

RNG  BRG 
RSB 

POS 

CHK 

DS 

On  the  keyboard,  the  key  labeled  DL  TOC  would  access  all  TOC  options 
and  would  have  “Uplink  held  TOC”  as  the  default  function.  The  secondary 
function  on  the  keyboard  DL  TOC  key  would  be  DS  (data  link  settings) 
which  would  be  accessed  by  depressing  the  multifunction  key  prior  to 
selecting  the  key.  The  DL  Menu  key  would  access  all  PDM  options. 

When  using  the  R-CRD  Category  Selection  area,  the  DL  TOC  and  DS 
functions  would  be  provided  by  separate  keys  since  no  multifunction 
capability  is  available  when  using  trackball  selection  in  DSR.  RNG  BRG 
and  RSB  could  be  combined  on  the  R-CRD  and  keyboard  because  the  total 
number  of  functions  for  these  categories  does  not  exceed  the  maximum  of 
10  for  any  category. 

If  two  keyboard  keys  cannot  be  provided  in  DSR  for  CPDLC-I,  the  only 
remaining  alternative  would  be  to  violate  the  Host  architecture  design 
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conventions  in  order  to  permit  the  use  of  a  single  Data  Link  key  while 
preserving  single  keystroke  access  to  all  important  message  types. 

4.2  ADAPTABLE  INITIAL  CONTACT  DATABASE  ALTITUDES. 

The  requirements  for  CPDLC-I IC  were  designed  to  be  compliant  with  FAA 
Directive  7110.65  Air  Traffic  Control.  This  directive  stipulates  that  the 
aircraft  data  block  must  reflect  the  aircraft’s  assigned  altitude.  Based  on 
this  guidance,  the  automated  check  of  an  aircraft’s  reported  altitude  for  the 
IC  service  was  designed  to  make  a  comparison  between  the  most  recent 
assigned  or  interim  altitude  entered  into  the  system  and  the  pilot’s 
downlinked  report. 

One  of  the  strongest  recommendations  of  the  group  concerned  this  aspect 
of  the  CPDLC-I  IC  service  design.  In  the  individual  design  reviews,  nine  of 
the  participants  noted  that  this  message  will  not  be  acceptable  unless  the 
software  used  to  check  the  pilot’s  downlinked  reported  altitude  is  modified 
to  permit  the  use  of  an  alternative  altitude  as  well  as  the  assigned  or 
interim  altitude  currently  stored  in  the  NAS  database. 

This  recommendation  was  driven  by  an  Order  modifying  7110.65  that  is  in 
force  at  many  ARTCCs  (including  Minneapolis)  which  states  that  an 
interim  altitude  entry  is  not  required  when  a  climbing  aircraft  is  assigned 
an  altitude  strictly  based  on  sector  stratification  and  is  expected  to  be 
recleared  to  a  higher  altitude  immediately  upon  hand-off  acceptance  by  the 
controller  of  the  receiving  sector  in  the  next  higher  altitude  strata.  This 
procedural  modification  is  based  on  paragraph  5-192b  of  the  7110.65  which 
stipulates  that  the  requirement  to  enter  an  interim  altitude  when  an 
aircraft  is  assigned  an  new  altitude  for  a  short  period  of  time,  and  will  be 
subsequently  recleared  to  a  new  altitude,  may  be  deleted  where  “heavy 
traffic  or  sector  complexity  precludes  such  action  and  compliance  is  not 
practicable.” 

During  the  debriefing  session  the  group  argued  that  failure  to  permit  the 
use  of  alternative  altitudes  for  aircraft  whose  flight  data  meet  specific 
criteria  would  result  in  a  high  rate  of  false  incorrect  altitude  report  alerts. 
This  outcome  would  lead  to  decreased  detectability  of  true  altitude 
mismatch  alerts  and  increased  controller  workload  involved  with  deleting 
the  alert.  It  was  noted  that  failure  to  resolve  this  design  deficiency  would 
be  likely  to  result  in  Minneapolis  controllers  abandoning  the  use  of  the  IC 
service  during  the  CPDLC-I  field  implementation. 
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4.3  “NO  RESPONSE  REQUIRED”  MESSAGE  TYPE  OPTION  FOR 
PREDEFINED  MESSAGES  (PPM). 


The  CPDLC  architecture  requires  that  all  messages  be  assigned  to  one  of 
four  categories  defined  by  the  types  of  pilot  response  that  will  be  accepted 
by  the  system.  In  CPDLC-I,  only  three  of  these  are  presently  included.  No 
provision  is  made  for  a  message  that  requires  no  response  from  the  flight 
deck. 

The  controllers  argued  that  this  omission  will  limit  the  utility  of  PDM 
because  most  noncritical  messages  that  can  be  sent  in  CPDLC-I  will  be 
informational,  and  many  of  these  will  be  sent  using  the  “ALL”  command. 
Such  messages  do  not  require  responses.  The  consequences  of  failing  to 
provide  a  “no  response”  option  would  be  added  aircrew  workload, 
unnecessary  clutter  in  the  status  list  when  the  “ALL”  command  is  used, 
and  the  potential  for  interference  with  ATC  operations  when  open 
transactions  unnecessarily  prevent  NAS  sector  hand  offs. 

4.4  FULL  DATA  BLOCK  EOUIPAGE/ELIGIBILITY  SYMBOLS. 

The  group  concurred  that  the  graphical  symbols  used  as  Data  Link 
equipage/eligibility  indicators  in  the  FDB  should  be  improved.  The  open 
diamond  and  hourglass  symbols  were  holdovers  from  the  PVD  prototype, 
which  has  a  restricted  symbol  set.  Early  ATDLVT  development  studies 
had  shown  that  these  symbols  should  be  changed  for  future  systems,  and 
that  open  and  closed  diamonds  would  be  preferred.  Nine  of  the  11 
participants  who  expressed  an  opinion  concurred  with  this  preference. 

It  was  recommended  that  the  diamond  symbology  be  used  for  CPDLC-I 
operational  effectiveness  testing.  However,  because  of  possible  confusion 
with  the  open  diamond  used  as  a  position  symbol,  it  was  suggested  that 
this  issue  be  addressed  during  testing.  If  the  results  indicate  that 
confusions  are  possible,  other  symbols  available  on  the  DSR  should  be 
examined  as  alternatives. 

4.5  D  CONTROT I ER  STATUS  LIST  AND  CATEGORY  KEYS. 

The  controllers  agreed  that,  because  the  D  controller  is  likely  to  be  a  user 
of  CPDLC-I,  Data  Link  inputs  and  displays  for  this  position  should  be 
improved  to  enhance  the  speed  and  accuracy  of  controller  performance. 
Specifically,  the  controllers  indicated  that  a  status  list  should  appear  on  the 
D  monitor  along  with  the  D-CRD.  As  a  minimum,  this  list  should  be  a 
repeater  of  the  R  status  list,  conforming  to  the  message  filter  settings  of  the 
R  list.  A  more  flexible  and  desirable  option  would  be  a  list  that  was 
independently  filterable  by  the  D  controller. 
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In  addition,  the  group  indicated  that  the  D  position  should  be  provided  with 
keyboard  category  keys  that  mirror  those  provided  on  the  R  keyboard. 
These  keys  would  provide  the  D  controller  with  the  capability  to  gain  one 
keystroke  access  to  Data  Link  functions  rather  that  using  the  more  time 
consuming  and  memory  intensive  two-letter  Host  designators. 

4.6  TRACKBALL  INPUTS  FOR  PPM  MESSAGE  SELECTION. 

The  controllers  indicated  that  both  trackball  and  single  keystroke  methods 
of  access  would  be  required  for  important  CPDLC-I  functions  to 
accommodate  different  controller  styles  of  interacting  with  DSR.  This 
argument  was  the  basis  for  requiring  two  Category  keys  to  provide  single 
keystroke  access  to  TOC  and  PDM. 

In  the  reviewed  design,  TOC  provides  the  controller  with  the  alternative 
trackball  selection  of  a  status  list  item  to  uplink  a  held  TOC  message. 
However,  no  equivalent  trackball  alternative  is  provided  for  PDM.  The 
group’s  recommendation  was  to  include  this  capability  for  CPDLC-I  by 
permitting  the  controller  to  trackball  select  a  menu  item  from  the  menu 
text  list  as  an  alternative  to  pressing  the  Data  Link  menu  key  and  entering 
the  menu  item  referent. 

4.7  TRANSFER  OF  COMMUNICATION. 

The  group  made  two  recommendations  for  minor  changes  to  Build  I  TOC 
commands.  The  commands  used  to  override  the  active  mode  for  a  single 
transaction  use  the  letter  M  to  change  to  manual  while  in  automatic  mode 
and  the  letter  T  to  change  to  automatic  while  in  manual  mode.  The 
controllers  agreed  that  M  should  be  changed  to  I  (Inhibit)  and  T  to  S 
(Send). 

The  primary  reason  for  this  change  was  a  perceived  improvement  in  the 
intuitiveness  of  the  commands  and  consistency  with  other  uses  of  these 
abbreviations  in  CPDLC  Build  II  where  M  will  be  used  for  Mach  and  T  for 
temporary  (altitude).  In  addition,  Build  II  will  reserve  several  other 
characters  for  Data  Link  inputs  (A,  T,  H,  K,  M,  I,  S,  R,  Z).  Avoiding  the  use 
of  these  in  Build  I,  it  was  argued,  will  ease  eventual  transition  at 
Minneapolis  ARTCC  and  prevent  possible  inadvertent  carry-over  of  the 
conflict  during  Build  n  development. 

The  controllers  also  noted  that  the  letter  O  is  used  in  the  command  to 
initiate  a  sector  handoff  without  preparing  or  sending  a  TOC  message.  The 
controllers  indicated  that  some  other  character  should  be  used  to  prevent 
confusion  with  the  number  zero. 
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Other  recommendations  regarding  TOC  included  making  “OFF”  the 
default  TOC  mode  on  startup  for  CPDLC-I  rather  than  “MAN”  or  “AUTO” 
to  prevent  inadvertent  preparation  or  sending  of  messages  by  a  controller 
not  using  Data  Link.  In  addition,  it  was  noted  that  the  automation  should 
be  adapted  to  enforce  the  CPDLC  procedure  forbidding  simultaneous 
engagement  of  auto  TOC  and  auto  handoff. 

Finally,  the  controllers  agreed  that  a  TOC  mode  indicator  (OFF/AUTO/ 
MAN)  should  be  continuously  presented  on  the  situation  display  to  ensure 
mode  awareness  and  prevent  errors.  This  indicator  was  predicted  to  be 
especially  useful  during  the  position  relief  process. 

4.8  OTHER  FINDINGS. 

Miscellaneous  inputs  and  recommendations  from  the  controllers  regarding 
the  CPDLC-I  interface  are  presented  in  the  following  list: 

a.  Error  status  messages  (e.g.,  FAI,  ERR,  EC)  in  the  Status  List  should 
be  highlighted  to  facilitate  detection. 

b.  Efforts  should  be  taken  to  simplify  supervisory  inputs  required  to 
modify  PDM  menus.  This  task  should  minimize  the  time  that  the 
supervisor  must  spend  away  from  the  control  area. 

c.  Modifying  Data  Link  Settings  should  not  require  the  controller  to 
memorize  complex  keyboard  entries.  Embedded  menus  that  can  be 
selected  with  the  trackball  would  insure  accurate  performance  when 
setting  service  modes  and  setting  filters  on  the  contents  of  the  status  list. 

d.  In  order  to  minimize  display  clutter,  the  status  list  should  not  be 
grouped  with  other  lists  (e.g.,  inbound,  hold,  departure)  for  the  purposes  of 
suppression,  setting  brightness  levels  etc. 

5.  CONCLUSIONS  AND  RECOMMENDATIONS. 

This  design  review  exercise  produced  data  on  controller  preferences  for 
the  assignment  of  display  system  replacement  (DSR)  Category  keys  to 
Controller-Pilot  Data  Link  Communication  Build  1  (CPDLC-I)  functions.  It 
also  generated  findings  based  on  subject  matter  expert  opinion  which 
indicate  that  modifications  are  needed  to  the  proposed  CPDLC-I  control, 
display,  and  service  designs. 

The  following  recommendations  from  the  design  review  are  grouped  into 
two  categories.  The  first  category  comprises  design  requirements  and 
changes  judged  by  the  participants  to  be  essential  to  the  successful 
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deployment  of  CPDLC-I  during  the  key  site  field  implementation.  A 
majority  of  the  participants  indicated  that  failure  to  implement  this  group 
of  recommendations  would  prevent  controllers  from  effectively  using  one 
or  more  of  the  CPDLC-I  services. 

The  second  category  of  recommendations  consists  of  improvements  that 
the  participants  felt  would  significantly  improve  the  acceptability  of 
CPDLC-I  and  the  effectiveness  and  accuracy  of  controller  performance. 

5.1  ESSENTIAL  REQUIREMENTS  AND  MODIFICATIONS. 

a.  To  conform  to  DSR/Host  command  structure  conventions  and 
provide  single  keystroke  access  to  primary  messages,  three  Category  Keys 
are  required  for  CPDLC-I.  Two  of  these  keys  must  be  assigned  to  transfer 
of  communication  (TOC)  and  predefined  messages  (PDM)  function 
categories.  The  third  should  be  assigned  to  Data  Link  Settings,  and  can  be 
a  secondary  function  on  one  of  the  Keyboard  Category  Keys  and/or  appear 
only  in  the  R-CRD  Category  Selection  Area. 

b.  The  initial  contact  (IC)  service  design  must  be  modified  to  permit 
the  downlinked  assigned  altitude  report  to  be  compared  to  an  adapted 
altitude  as  well  as  the  assigned  or  interim  altitudes  contained  in  the 
National  Airspace  Systems  (NAS)  database. 

c.  The  “no  response  required”  message  type  must  be  added  to  the 
current  set  of  response  options. 

5.2  MODIFICATIONS  TO  IMPROVE  CONTROLLER  ACCEPTANCE 

AND  PERFORMANCE. 

a.  The  Full  Data  Block  (FDB)  equipage/eligibility  indicators  should 
be  changed.  An  open  diamond  should  be  used  to  indicate  that  the  aircraft 
is  currently  capable  for  Data  Link  communications  and  the  observing 
sector  is  not  eligible.  A  filled  diamond  should  be  used  to  indicate  that  the 
observing  sector  is  eligible  to  communicate  with  the  aircraft  via  Data  Link. 
The  effectiveness  of  this  symbology  should  be  investigated  in  simulation 
testing  prior  to,  or  during  CPDLC-I  Operational  Testing. 

b.  A  Status  List  should  be  available  on  the  D  controller  display. 

c.  Category  Keys  for  CPDLC-I  functions  should  be  provided  on  the 
D  Controller  Keyboard. 
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d.  The  option  should  be  provided  to  permit  selection  of  a  message 
from  the  PDM  menu  by  trackball  designation  of  the  item  as  well  as  by  the 
keyboard  entry  method. 

e.  The  commands  used  to  override  the  active  TOC  mode  for  a  single 
transaction  should  be  changed.  The  letter  “I”  (inhibit)  should  be  entered  in 
the  command  sequence  to  change  to  manual  while  in  the  automatic  mode. 
The  letter  “S”  (send)  should  be  used  to  change  to  automatic  while  in  the 
manual  mode. 

f.  The  letter  entry  O  used  in  the  command  to  initiate  a  sector  hand 
off  without  preparing  or  sending  a  TOC  message  should  be  changed  to 
another  letter  in  order  to  avoid  confusion  with  the  number  zero. 

g.  The  default  mode  for  TOC  should  be  “OFF”  rather  than  “AUTO” 
or  “MANUAL”. 

h.  The  automation  should  be  adapted  to  enforce  the  procedure 
forbidding  simultaneous  engagement  of  auto  handoff  and  auto  TOC. 

i.  A  TOC  active  mode  indicator  (OFF,  MAN,  or  AUTO)  should  be 
continuously  present  on  the  situation  display. 

j.  Status  indicators  of  errors  in  the  Status  List  (e.g.,  ERR,  FAI,  EC) 
should  be  highlighted. 

k.  Embedded  menus  should  be  used  to  select  options  when  setting 
status  list  filters  and  selecting  service  modes. 

l.  The  location  of  input  devices  for  supervisory  inputs  to  PDM  and 
the  user  interface  should  be  designed  to  minimize  time  away  from  the 
control  area. 
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6.  ACRONYMS  AND  ABBREVIATIONS. 


ARTCC 

Air  Route  Traffic  Control  Center 

ASM 

Altimeter  Setting  Messages 

ATC 

Air  Traffic  Control 

ATDLVT 

Air  Traffic  Data  Link  Validation  Team 

ATN 

Aeronautical  Telecommunications  Network 

AUA 

Air  Traffic  Systems  Development 

CHI 

Computer-Human  Interface 

CPDLC 

Controller-Pilot  Data  Link  Communications 

CPDLC-I 

Controller-Pilot  Data  Link  Communication  Build  I 

DL 

Data  Link 

DSR 

Display  System  Replacement 

DYSIM 

Dynamic  Simulation 

EMER  CHK 

Emergency  Check 

FAA 

Federal  Aviation  Administration 

FDB 

Full  Data  Block 

IC 

Initial  Contact 

ICAO 

International  Civil  Aviation  Organization 

MULTI  FUNC 

Multi  Function 

NAS 

National  Airspace  System 

NATCA 

National  Air  Traffic  Control  Association 

OT 

Operational  Test 

PDM 

Predefined  Messages 

POS  CHS 

Position  Check 

PVD 

Plan  View  Display 

R-CRD 

Radar  Computer  Readout  Device 

RNG  BRG 

Range  Bearing 

RSB 

Radar  Sort  Box 

TOC 

Transfer  of  Communication 

VHF 

Very  High  Frequency 
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APPENDIX  A 


Individual’s  Consent  to  Voluntary  Participation  in  a  Research  Project 


FAA  William  J.  Hughes  Technical  Center 

Individual’s  Consent  to  Voluntary  Participation  in  a  Research  Project 

I _ ,  understand  that  this  study  entitled  “User 

Involvement  Study:  Design  Review  of  the  Display  System  Replacement 
Computer-Human  Interface  for  Controller-Pilot  Data  Link  Communications  - 
Build  I”  is  sponsored  by  the  Federal  Aviation  Administration  and  is  being  directed 
by  the  Data  Link  Branch  (ACT-350)  of  the  Communications,  Surveillance  and 
Navigation  Division. 

I  have  been  recruited  to  volunteer  as  a  participant  in  the  project  named  above. 
The  purpose  of  this  project  is  to  obtain  expert  controller  input  regarding  the 
design  of  the  inputs  and  displays  that  will  be  used  to  provide  an  initial  Controller- 
Pilot  Data  link  Communication  Build  1  (CPDLC-I)  capability  on  the  Display 
System  Replacement  (DSR)  controller  workstation. 

Nature  and  Purpose. 

The  project  will  involve  my  participation  over  a  period  of  3  days.  There  will  be 
approximately  nine  other  en  route  ATCSs  participating  with  me.  The  project 
activities  will  take  place  during  normal  workdays  with  breaks  for  meals.  I  will  be 
required  to  attend  classroom  training  sessions  and  practice  sessions  in  the  ATC 
simulation  laboratories  to  acquaint  me  with  Data  Link  and  the  DSR.  I  will  then 
perform  an  individual  evaluation  of  the  CPDLC-I  computer-human  interface 
(CHI) ,  and  participate  in  a  group  debriefing. 

Study  Procedures. 

The  study  will  begin  with  a  classroom  training  session  on  the  CPDLC  CHI 
originally  developed  for  the  Host/PVD  system.  This  will  be  followed  by 
simulation  exercises  in  the  ATC  simulation  laboratory  to  familiarize  me  with  the 
Data  T  ink  commands  and  displays  as  implemented  on  the  PVD.  Next,  classroom 
training  on  the  display  and  input  conventions  of  the  DSR  will  be  provided  along 
with  hands-on  simulation  exercises  on  the  DSR.  Finally,  a  classroom  session  will 
be  used  to  describe  and  illustrate  the  proposed  CPDLC-I  CHI  for  DSR. 

I  will  use  these  experiences  as  a  basis  for  completing  an  individual  design  review 
of  the  proposed  CPDLC-I  CHI  for  DSR.  The  design  review  booklet  will  provide  a 
description  of  each  design  feature  and  provide  space  for  my  comments  and 
recommendations.  It  will  also  allow  me  to  express  my  preferences  regarding 
certain  unresolved  design  issues.  The  project  will  conclude  with  a  structured 
group  debriefing  to  identify  individual  areas  of  concern  and  to  achieve  consensus 
where  possible. 
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Discomfort  and  Risks. 


I  understand  that  there  are  minimal  physical  or  psychological  risks  associated 
with  participation  in  this  study.  The  Host/PVD  simulation  facilities  use 
equipment  and  workstations  that  are  identical  to  those  currently  used  by  en  route 
controllers  in  ARTCCs.  The  DSR  simulation  laboratory  uses  preproduction 
models  of  the  DSR  workstation  that  will  be  installed  in  ARTCCs  to  replace  the 
PVD.  The  tasks  that  I  will  perform  in  the  laboratories  will  be  the  same,  or  similar, 
to  those  I  perform  in  my  job  as  an  ATCS. 

Precautions  for  Female  Participants. 

The  risks  of  participating  in  this  study  are  substantially  the  same  as  those 
encountered  by  operational  en  route  ATCSs  performing  their  normal  duties.  If  I 
am  a  female  ATCS,  I  understand  that  I  must  exercise  the  same  precautions  that  I 
would  at  my  job  to  avoid  risks  to  myself,  the  embryo  or  fetus  if  I  currently  am,  or 
may  become  pregnant. 

Benefits. 

I  understand  that  the  only  direct  benefit  to  me  is  that  I  will  receive  my  normal 
FAA  pay  and  travel  reimbursement  while  participating  in  this  study. 

Participant  Responsibilities. 

I  understand  that  by  volunteering  for  this  study  that  I  accept  the  obligation  to 
make  an  honest  evaluation  of  the  CPDLC-I  CHI  for  DSR  based  on  my  past 
experience  as  an  en  route  ATCS  and  on  the  information  and  simulation 
experiences  that  are  provided  to  me  during  this  study. 

Compensation  and  Injury. 

I  agree  to  report  any  personal  injury  or  suspected  adverse  effect  of  this  study  to 
Mr.  Darby  at  609-485-6345.  I  understand  that,  as  an  official  government 
employee  duty,  accident  insurance  coverage  for  this  study  activity  is  provided  by 
the  Workmen’s  Compensation  Insurance  Fund  in  relation  to  my  Federal 
Government  employment. 
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Participant’s  Assurances. 


I  understand  that  my  participation  in  this  study  is  completely  voluntary.  I  am 
participating  because  I  want  to.  Mr.  Darby  has  adequately  answered  any  and  all 
questions  that  I  have  about  this  study,  my  participation,  and  the  procedures 
involved.  I  understand  that  Mr.  Darby  will  be  available  to  answer  questions 
concerning  procedures  throughout  this  study. 

I  have  not  given  up  any  of  my  legal  rights  or  released  any  individual  or  institution 
from  liability  for  negligence. 

I  understand  that  records  of  this  study  will  be  kept  confidential,  and  that  I  will 
not  be  identifiable  by  name  or  description  in  reports  or  publications  about  this 
study. 

I  understand  that  I  may  withdraw  from  this  study  at  any  time  without  penalty  or 
loss  of  benefits  to  which  I  am  otherwise  entitled. 

If  I  have  questions  about  this  study  or  need  to  report  adverse  effects  from  the 
study  activities,  I  will  contact  Mr.  Darby  at  609-485-6345  during  the  workday  or 
1-800-832-2506  at  sill  other  times. 

I  have  read  this  consent  document.  I  understand  its  contents,  and  I  freely 
consent  to  participate  in  this  study  under  the  conditions  described.  I  have 
received  a  copy  of  this  consent  form. 

Study  Participant: _  Date: _ 


Investigator: 


Date: 


Witness: 


Date: 
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APPENDIX  B 


Controller  Design  Review  Booklet 


CPDLC-I 


CONTROLLER  DESIGN  REVIEW  BOOKLET 


This  booklet  contains  a  series  of  questions  that  will  permit  you  to  independently 
review  the  CPDLC-I  services  that  will  be  implemented  on  the  DSR.  The  goals  of 
this  review  are  to  (1)  resolve  some  open  design  issues,  and  (2)  obtain  your  inputs 
and  recommendations  regarding  the  service  designs. 

Please  answer  all  of  the  questions  in  this  booklet  and  carefully  record  your 
comments  and  any  recommendations.  Please  explain  your  reasons  for 
suggesting  any  changes. 

Your  primary  task  during  this  exercise  is  to  concentrate  on  completing  the 
review  booklet.  We  are  doing  the  review  in  the  DSR  laboratory  in  order  to  give 
you  the  opportunity  to  examine  the  DSR  displays  and  keyboard  layout  in  the 
course  of  making  your  evaluations. 


Reviewer’s  Name 
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PARTI 


Data  Link  Key  Options 

The  CPDLC-I  CHI  for  DSR  requires  a  capability  for  controllers  to  select  two 
unique  groups  of  Data  Link  functions.  The  Data  Link  function  (DL)  is  used  to 
compose  and  send  messages.  The  Data  Link  Settings  function  (DS)  is  used  to 
set  the  Transfer  of  Communications  mode,  the  Altimeter  Setting  mode,  display  a 
list  of  current  sector  Data  Link  settings,  and  to  select  or  modify  the  contents  of 
Data  Link  lists. 

To  select  these  function  groups  from  the  D  position,  the  controller  will  be 
required  to  enter  two-character  Host-type  designators  on  the  alphanumeric 
keyboard.  At  the  R  position,  category  keys  located  on  the  keyboard  or  in  the  R- 
CRD  view  may  be  used  as  the  DL  and  DS  keys.  Selecting  one  of  the  keys  will 
display  a  menu  in  the  R-CRD  text  area  referring  to  the  soft  function  keys  that 
must  be  depressed  (or  selected  by  trackball  in  the  R-CRD  category  selection 
area)  to  complete  the  command.  One  of  the  functions  displayed  in  the  text  area 
will  be  highlighted,  designating  it  as  the  “hot”  function.  TTie  “hot”  function  need 
not  be  selected  when  completing  the  associated  command  sequence. 

Instructions 

The  following  list  presents  three  overall  category  key  assignment  options  for  the 
DL  and  DS  functions  at  the  R  position.  In  evaluating  these  options  you  should 
consider  how  often  controllers  will  use  the  Data  Link  functions  as  well  as  other 
functions  selected  from  the  Category  Keys  and  R-CRD  Category  Selection  Area. 
You  also  should  consider  the  ease  and  accuracy  with  which  controllers  will  be 
able  to  locate  and  activate  functions  positioned  in  various  places  on  the  DSR 
keyboard. 

Please  rank  the  options  from  1  “most  acceptable”  to  3  “least  acceptable”.  If  you 
feel  that  an  option  would  be  completely  unacceptable  to  controllers,  do  not  assij 
a  rank  to  that  option  and  write  the  letter  “U”  in  the  blank. 

After  ranking  the  overall  options  that  would  be  acceptable,  select  the  specific 
implementation  of  the  options  that  you  feel  would  be  preferable  to  controllers. 
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_  Option  A:  Redefine  Two  Keyboard  Category  Keys 

Rank 

Redefine  two  of  the  keyboard  Category  Keys  as  DL  and  DS.  The  original 
functions  of  the  redefined  keys  would  remain  available  in  the  R-CRD  Category 
Selection  Area. 

Select  two  Category  Keys  that  would  be  most  acceptable  for  redefinition  under 
this  option  from  the  following: 

POS  CHK 
EMERG  CHK 
SIM 

MET  LIST 

DL  key  choice: _ 

DS  key  choice:  _ _ 


_  Option  B:  Redefine  One  Keyboard  Category  Key 

Rank 

Redefine  one  of  the  keyboard  Category  Keys  as  the  DL  key  and  make  the  DS  key 
function  available  only  in  the  Category  Selection  Area  of  the  R-CRD.  The 
original  function  of  the  redefined  keyboard  Category  Key  would  remain  available 
in  the  R-CRD  Category  Selection  Area. 

Select  one  keyboard  Category  Key  that  would  be  most  acceptable  for  redefinition 
as  the  DL  key  under  this  option: 

POS  CHK 
EMERG  CHK 
SIM 

MET  LIST 

DL  key  choice: _ _ 
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_  Option  C:  Combine  Two  Category  Key  Functions 

Rank 

Combine  two  of  the  existing  keyboard  Category  Key  functions  onto  one  key,  and 
use  the  free  Category  Key  as  the  DL  key.  Make  the  DS  key  function  available 
only  in  the  Category  Selection  Area  of  the  R-CRD. 

The  following  combinations  would  be  allowable  in  DSR.  Select  one  that  would  be 
most  acceptable  under  this  option: 

_  RSB  and  RNG  BRG  in  RSB  position  (DL  in  RNG  BRG 

position) 

_  RSB  and  RNG  BRG  in  RNG  BRG  position  (DL  in  RSB 

position) 


Comments: 
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Instructions  for  Parts  II  -  VI 


The  next  five  parts  of  this  booklet  will  permit  you  to  perform  a  detailed  review  of 
the  CPDLC-I  controller  interface  design.  Each  part  begins  with  a  design 
description.  Read  these  descriptions  carefully  before  recording  your  comments. 

NOTES  ON  CONVENTIONS  USED  IN  THE  DESIGN  DESCRIPTIONS 


-  Data  as  shown  in  a  display  or  entered  on  the  keyboard  are  presented  in 
quotation  marks.  When  spaces  Eire  required,  they  are  included  within  the 
quotation  marks.  The  quotation  marks  are  not  part  of  the  display  or  entry. 

-  All  spaces  included  within  quotation  marks  for  keyboard  entries  are 
mandatory.  For  example,  "MT  ON"  should  be  interpreted  as  typing  MT,  a 
space,  and  ON. 

-  Input  commands  printed  in  bold  italics  refer  to  a  DSR  keyboard  category,  soft 
function,  or  function  (QAK)  key,  or  a  “key”  in  the  R-CRD  Category  Selection 
Area  (e.g.,  DL,  DS,  FI). 

-  Two  trackball  keys  are  used.  Trackball  ENTER  (middle  key)  is  used  to 
complete  a  command  sequence.  Trackball  SELECT  (left  key)  is  used  to 
identify  an  item  in  the  R-CRD  text  area  or  the  Status  List  and  to  identify  lists 
for  moving  them  on  the  display. 

-  FLID  refers  to  any  NAS  command  for  identifying  a  flight  including: 

.  The  Aircraft  Identification  Call  Sign  (AID) 

.  The  Computer  Identification  Number  (CID) 

.  The  Beacon  Code 

.  Positioning  the  trackball  cursor  over  the  data  block  and  pressing 
trackball  ENTER 


-  All  keyboard  entries  must  be  followed  by  a  keyboard  ENTER  or  a  trackball 
ENTER  to  complete  the  command  sequence. 
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Part  II 


Status  List  and  Full  Data  Block 


-  Function 

The  Full  Data  Block  (FDB)  provides  unique  graphic  characters  which  indicate 
that  an  aircraft  is  equipped  to  receive  Data  Link  messages,  and  whether  the 
observing  control  position  is  eligible  to  uplink  messages  to  the  aircraft.  The  FDB 
also  provides  limited  information  about  the  status  of  ongoing  Data  Link 
transaction. 

The  Status  List  is  a  Host  situation  display  tabular  list  that  contains  full 
information  about  the  content  and  current  status  of  ongoing  Data  Link 
transactions.  The  Status  List  does  not  appear  on  the  D  position  display. 

-  Full  Data  Block  Equipage  and  Eligibility  Indicators 

Data  Link  equipage  and  eligibility  are  indicated  by  graphic  characters  located  in 
the  first  position  of  the  first  line  of  the  FDB.  No  special  character  in  this  position 
identifies  an  aircraft  that  is  not  capable  of  communicating  via  Data  Link.  An 
“open  diamond”  (0)  indicates  that  the  aircraft  is  Data  Link  equipped,  but  that  the 
viewing  sector  position  is  ineligible  to  communicate  with  it.  An  “hour  glass” 

(x)  indicates  that  the  aircraft  is  equipped  and  that  the  viewing  sector  is  eligible. 

-  Status  List  Format 

The  Status  List  is  identified  by  "SL"  displayed  in  the  upper  left  comer  of  the  list. 
Each  line  of  the  list  contains  information  about  one  ongoing  transaction.  A  line 
has  three  data  fields  displaying  (1)  the  aircraft  identification,  (2)  an  abbreviated 
version  of  the  content  of  the  uplinked  message,  and  (3)  and  an  indication  of  the 
current  status  of  the  transaction.  For  example,  "UAL172  123.125  SNT"  would 
indicate  that  the  controller  had  uplinked  a  message  to  UAL  172  to  switch  radio 
frequencies  to  123.125  and  that  the  message  is  in  the  sent  status. 

-  Status  List  Abbreviations  of  Transaction  Status 

The  third  field  of  a  status  line  presents  the  following  abbreviations  to  indicate  the 
current  status  of  the  transaction: 

“SNT”  -  Sent:  A  controller  input  or  system  event  has  initiated  the  uplink. 
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“HLD”  -  Held:  A  transfer  of  communication  message  containing  the  radio 
frequency  of  a  new  airspace  sector,  which  the  aircraft  will  enter,  has 
been  prepared  and  is  ready  for  uplink  when  the  sending  controller 
makes  an  appropriate  input. 

“ROG”  -  Roger 

“AFF”  -  Affirmative 

“WIL”  -  Wilco:  The  system  has  received  a  downlink  from  the  flight  deck 
indicating  that  the  pilot  has  received  the  message  /  agrees  with  /  or 
will  comply  with  the  uplinked  message. 

“NEG”  -  Negative 

“UNB”  -  Unable:  The  system  has  received  a  downlink  from  the  flight  deck 
indicating  that  the  pilot  has  received  the  the  uplinked  message,  but 
does  not  agree  with  /  is  unable  to  comply. 

“TIM”  -  Time  Out:  A  timer  initiated  when  the  uplinked  message  was  sent 
has  expired.  This  is  an  adaptable  time  parameter  nominally  set  at  40 
seconds.  The  time  out  status  is  an  indication  to  the  controller  of  an 
unusually  lengthy  delay  for  receipt  of  a  response  from  the  aircraft. 
The  transaction  remains  open,  and  a  subsequent  response  will  be 
accepted  by  the  system. 

“FAI”  -  Failed:  The  system  failed  to  successfully  deliver  the  message  to 
the  service  provider 

“ERR”  -  Error:  Indicates  that  the  service  provider  was  unable  to  deliver  the 
message  to  the  aircraft  within  the  maximum  allowable  time. 

All  states  that  close  a  transaction  with  a  positive  response  (ROG,  WIL,  AFF)  will 
delete  the  relevant  line  on  the  Status  list  after  an  adjustable  time  parameter 
(nominally  6  seconds)  has  expired.  Messages  in  any  other  transaction  state 
must  be  manually  deleted  using  inputs  described  in  succeeding  sections  of  this 
booklet. 

-  Full  Data  Block  Indications  for  CPDLC-I  Services  and  Status 

FDB  indicators  are  correlated  with  the  Status  List  indicators,  but  vary  depending 
upon  the  service  involved.  They  are  described  in  detail  under  succeeding 
sections  devoted  to  each  service. 
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-  Inputs  to  Move  the  Status  List 

The  Status  List  can  be  moved  to  any  position  on  the  situation  display  by  using  the 
trackball  to  SELECT  the  header  area  of  the  list  and  pressing  the  trackball 
ENTER  to  indicate  the  list’s  new  position. 

-  Inputs  to  Suppress  or  Retrieve  the  Status  List 

The  Status  List  can  be  suppressed  by  typing  DS  F9  “OFF”.  The  list  is  retrieved  to 
the  situation  display  by  typing  DS  F9  ”ON”.  These  entries  cannot  be  made  from 
the  D  position. 

-  Selecting  Message  Types  for  Display  in  the  Status  List 

The  Status  List  will  display  information  on  all  four  types  of  message  included  in 
CPDLC-I.  However,  the  controller  can  selectively  suppress  Status  List  content  by 
message  category.  The  following  table  presents  the  commands  used  to 
selectively  suppress  and  retrieve  each  message  type. 


R  Position  Only 

R  and  D  Position 

Transfer  of 

DS  F8  “TC  OFF”  or 

“SVTC  OFF”  or 

Communication 

DSF8“  TCON” 

“SV  TC  ON” 

Menu 

DS  F8  “MT  OFF”  or 

“SVMT  OFF”  or 

Text 

DS  F8  “MT  ON” 

“SV  MT  ON” 

Initial 

DSF8  “ICOFF”  or 

“SV  ICOFF”  or 

Contact 

DS  F8  “IC  ON” 

“SVICON” 

Altimeter 

DSF8  “AS  OFF”  or 

“SVAS  OFF”  or 

Setting 

DS  F8  “AS  ON” 

“SVASON” 

All  Message 

DSF8  “OFF”  or 

“SV  OFF”  or 

Types 

DS  F8  “ON” 

“SV  ON” 

It  is  also  possible  to  display  or  suppress  multiple  message  types  in  a  single 
command  (e.g.,  DS  F8 “TC  MT  OFF”). 

-  Selecting  Message  States  for  Display  in  the  Status  List 

The  controller  also  can  determine  the  messages  that  will  appear  in  the  Status  List 
by  their  respective  states.  The  following  table  presents  the  commands  used  to 
selectively  suppress  and  retrieve  the  display  of  messages  in  four  states. 

Messages  with  any  other  status  cannot  be  suppressed. 


B-8 


R  Position  Only 

R  and  D  Position 

SENT 

DSF10“SNT  OFF”  or 
DS  F10“SNT  ON” 

“SZ  SNT  OFF”  or 
“SZ  SNT  ON” 

ROGER 

DSF10  “ROG  OFF”  or 
DS  FI 0  “ROG  ON” 

“SZ  ROG  OFF”  or 
“SZ  ROG  ON” 

WILCO 

DS  FI  0  “WILOFF”  or 
DS  F10  “WIL  ON” 

“SZ  WIL  OFF”  or 
“SZ  WIL  ON” 

AFFIRMATIVE 

DSF10  “AFF  OFF”  or 
DS  F10  “AFF  ON” 

“SZ  AFF  OFF”  or 
“SZAFFON” 
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Full  Data  Block  and  Status  List  Evaluation 
Please  record  your  comments  and  recommendations  here. 
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Part  III 


Transfer  of  Communication  (TOC) 


-  Function 

The  Data  Link  transfer  of  communication  message  is  automatically  prepared 
when  the  receiving  controller  accepts  a  handoff  for  an  equipped  aircraft.  The 
sending  controller  has  the  option  to  send  the  new  frequency  automatically  when 
the  handoff  is  accepted,  or  to  send  the  message  manually  at  a  later  time. 

-  Inputs  to  Set  the  Transfer  of  Communication  Mode 

Transfer  of  communication  can  be  set  to  the  automatic  mode  by  typing  DS  FI 
“AUTO”  (R  position)  or  “AT  AUTO”  (D  position).  The  manual  mode  is  selected 
by  typing  DS  FI  “MAN”  (R  position)  or  “AT  MAN”  (D  position). 

Data  T  ink  transfer  of  communication  capability  can  be  turned  off  for  the  sector 
by  typing  DS  FI  “OFF”  (R  position)  or  “AT  OFF”  (D  position). 

-  Manual  and  Automatic  Send  Inputs 

When  in  the  automatic  mode,  the  transfer  of  communication  message  will  be 
uplinked  with  no  additional  action  by  the  sending  controller  when  the  receiving 
sector  accepts  the  handoff. 

When  in  the  manual  mode,  acceptance  of  the  handoff  will  store  the  message  for 
later  transmission.  The  message  will  appear  in  the  Status  List  in  the  “HLD” 
status.  The  controller  can  send  the  message  by  a  trackball  slew/ENTER  to  the 
“dot”  preceding  the  appropriate  line  in  the  Status  List  or  by  typing  DL  FI  (R 
position  only)  or  “UH”  followed  by  the  FLID.  (Note  that  the  FI  key  entry  may  be 
omitted  because  it  is  the  “hot”  key) 

When  using  keyboard  entries  for  the  transfer  of  communication,  frequencies 
other  than  the  primary  default  frequency  can  be  substituted.  Typing  “U” 
followed  by  a  space  before  the  FLID  will  substitute  a  predefined  alternate 
frequency.  Typing  a  numeric  radio  frequency  value  in  the  same  position  will 
send  that  frequency  if  adapted  for  the  facility. 
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-  Status  List  and  Full  Data  Block  Displays  on  Transfer  of 
Communication 

The  Status  List  entry  for  a  transfer  of  communication  transaction  presents  the 
AID,  the  uplinked  frequency,  and  the  current  transaction  status  message.  When 
in  a  manual  mode,  the  "HLD"  status  message  is  displayed  until  the  controller 
completes  the  slew  action  or  keyboard  entries  to  send  the  message.  In  the 
automatic  mode,  the  status  line  appears  in  the  "SNT"  state  immediately  after 
acceptance  of  the  handoff. 

In  either  mode  of  operation,  when  the  transfer  of  communication  message  is 
sent,  a  “pound”  symbol  (#)  replaces  the  Data  Link  equipage/eligibility  indicator 
in  the  first  position  of  the  first  line  of  the  Full  Data  Block.  This  symbol  will 
appear  at  all  sectors  displaying  the  aircraft’s  Full  Data  Block.  When  the  wilco  is 
received  from  the  flight  deck,  the  pound  symbol  is  replaced  by  the  hourglass  in 
the  receiving  sector  and  by  the  open  diamond  in  all  other  sectors. 

In  an  interfacility  transfer  of  communication,  the  receiving  sector  will  display  the 
hourglass  and  all  Data  Link  eligibility  symbology  will  be  removed  from  sectors  in 
the  sending  facility. 

-  Unable  and  Time  Out  Displays  for  Transfer  of  Communication 
and  Controller  Responses. 

If  the  flight  deck  responds  to  a  transfer  of  communication  message  with  an 
unable,  "UNB"  is  displayed  in  the  status  field  of  the  Status  List.  If  the  flight  deck 
fails  to  downlink  a  response  within  40  seconds  (adaptable)  after  the  message  was 
sent,  "TIM"  is  displayed  in  the  status  field. 

The  unable  conditions  also  will  cause  the  pound  symbol  in  the  first  position  of  the 
first  line  of  the  sending  controller's  Full  Data  Block  to  revert  to  the  hourglass 
symbol  indicating  that  Data  Link  eligibility  remains  at  the  sending  sector.  All 
other  sectors  will  display  the  open  diamond. 

-  Deleting  Transfer  of  Communication  Transactions 

The  controller  can  close  the  transaction  and  delete  "UNB”,  “ERR”,  or  “FAI” 
indicators  by  typing  DL  F3“ TC  “  and  the  FLID  (R  position  only)  or  “DE  TC”  and 
the  FLID.  If  the  controller  chooses  to  delete  a  transaction  in  the  “SNT”  or  “TIM” 
states  “/OK”  must  be  included  in  the  command  sequence  prior  to  “TC”  (e.g.,  DL 
F3“ /OK  TC  USA219”).  The  transaction  can  also  be  deleted  by  eliminating  the 
“TC”  in  the  command  and  using  the  trackball  to  select  the  dot  preceding  the 
appropriate  line  in  the  Status  List. 
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-  Sending  an  Automatic  Transfer  of  Communication  When  in  Manual 
Mode 

While  working  in  the  manual  mode,  the  controller  can  selectively  choose  to  send 
the  message  automatically  to  an  individual  aircraft  by  adding  a  single  keystroke 
to  the  normal  sequence  used  to  offer  a  handoff.  The  transfer  of  communication 
message  will  be  sent  automatically  upon  handoff  acceptance  if  the  controller 
offers  the  handoff  by  typing  the  two-digit  receiving  sector  number, "  T ",  and  the 
FLID  (e.g.,  "22  T  USA435).  Alternate  frequency  options  may  be  included  in  the 
command.  Only  one  aircraft  may  be  designated  in  the  message.  Adding  the  "T" 
to  a  single  handoff  command  will  not  affect  other  subsequent  aircraft  handoffs, 
and  the  selected  mode  will  remain  manual. 

-  Holding  a  Transfer  of  Communication  When  in  Automatic 
Mode 

While  working  in  the  automatic  mode,  the  controller  can  selectively  choose  to 
hold  the  message  for  an  individual  aircraft  by  adding  a  single  keystroke  to  the 
normal  sequence  used  to  offer  a  handoff.  The  transfer  of  communication 
message  will  be  put  into  the  held  status  upon  handoff  acceptance  if  the  controller 
offers  the  handoff  by  typing  the  two-digit  receiving  sector  number, "  M ",  and  the 
FLID  (e.g.,  "22  M  USA435).  Alternate  frequency  options  may  be  included  in  the 
command.  Only  one  aircraft  may  be  designated  in  the  message.  Adding  the  "M" 
to  a  single  handoff  command  will  not  affect  other  subsequent  aircraft  handoffs, 
and  the  selected  mode  will  remain  automatic. 

-  Changing  Data  Link  Eligibility  Without  a  Handoff 

If  a  controller  has  track  control  for  an  aircraft,  Data  Link  eligibility  can  be 
acquired  from  another  sector  in  the  absence  of  a  completed  handoff  by  typing  DL 
F8  (R  position  only)  or  “SX”  followed  by  the  FLID.  This  action  does  not  uplink 
the  acquiring  sector’s  radio  frequency  to  the  aircraft. 

Track  control  and  Data  Link  eligibility  can  be  acquired  from  another  sector  in  the 
absence  of  a  handoff  with  a  single  input  by  typing  “/OK  D”  and  the  FLID. 

CPDLC-I  does  not  permit  the  controller  to  “force”  Data  Link  eligibility  to  another 
sector. 
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-  Sending  a  Radio  Frequency  to  an  Aircraft  Without  a  Handoff 

A  controller  at  the  R  position  who  has  Data  Link  eligibility  can  send  his/her 
sector’s  radio  frequency  to  the  aircraft  by  typing  DL  FI 0  and  the  FLID. 

Frequencies  other  than  the  primary  default  frequency  for  the  sector  can  be 
substituted.  Typing  “UF”  followed  by  a  space  before  the  FLID  will  substitute  a 
predefined  alternate  frequency.  Typing  a  numeric  radio  frequency  value  in  the 
same  position  will  send  that  frequency  if  adapted  for  the  facility. 

When  a  frequency  is  sent  in  this  manner,  the  message  will  instruct  the  pilot  to 
“monitor”  the  new  frequency.  If  “C”  is  inserted  in  the  message  after  FI 0  or  UF, 
the  message  will  instruct  the  pilot  to  “contact”  the  controller  on  the  new 
frequency  (e.g.,  “UF  C  NWA899). 

-  Initiating  a  Handoff  without  Preparing  a  Transfer  of  Communication 
Message 

An  aircraft  that  is  Data  Link  eligible  can  be  handed  off  without  preparing  or 
sending  a  transfer  of  communication  message  by  typing  the  receiving  sector’s 
number,  “O”  and  the  FLID  (e.g.,  “22  O  USA219”). 
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Transfer  of  Communication  Evaluation 
Please  record  your  comments  and  recommendations  here. 
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Part  IV 


Initial  Contact  (IC) 


-  Function 

This  service  substitutes  the  initial  radio  call  from  the  flight  deck  after  a  transfer 
of  communication  with  a  downlink  report  of  assigned  altitude.  Under  normal 
conditions,  the  initial  contact  procedure  is  automatic  and  transparent,  and 
requires  no  controller  interaction. 

-  Initial  Contact  Procedure 

An  altitude  request  message  is  automatically  appended  to  the  radio  frequency 
assignment  message  that  is  uplinked  during  transfer  of  communication.  The 
flight  deck  responds  to  the  transfer  of  communication  uplink  by  downlinking  a 
wilco  along  with  a  report  of  assigned  altitude  to  the  receiving  controller. 

Receipt  of  the  wilco  response  transfers  Data  Link  eligibility  to  the  receiving 
sector.  In  addition,  the  reported  assigned  altitude  is  automatically  checked 
against  the  aircraft's  assigned  altitude  (or  interim  altitude)  recorded  in  the  NAS 
database.  If  the  aircraft's  reported  downlinked  assigned  altitude  matches  the 
database  value,  nothing  is  displayed  at  the  sending  or  receiving  sectors,  and  no 
additional  controller  action  is  required. 

Note  that  the  transfer  of  communication  message  will  normally  instruct  the  pilot 
to  “monitor”  the  new  frequency.  If  the  receiving  sector  is  not  using  the  Initial 
Contact  Data  Link  service,  it  will  instruct  the  pilot  to  “contact”  the  controller  at 
the  new  frequency  and  no  altitude  request  will  be  sent. 

-  Discrepancy  Between  Reported  and  Assigned  Altitudes 

If  the  reported  assigned  altitude  fails  to  match  the  assigned  or  interim  altitude 
contained  in  the  NAS  database,  the  downlinked  value  followed  by  “I”  will  appear 
in  the  first  four  positions  of  the  second  line  of  the  Full  Data  Block.  This  will 
timeshare  every  1.5  seconds  with  the  database  value  followed  by  the  altitude 
conformance  indicator.  If  the  Mode  C  altitude  had  been  displayed  in  this  field 
when  the  timesharing  began,  the  Mode  C  altitude  would  be  shifted  to  the  right  of 
the  second  line  to  make  it  continuously  viewable. 
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In  addition  to  the  Full  Data  Block  display,  a  Status  List  entry  will  be  created 
displaying  the  AID,  the  NAS  data  base  altitude,  and  the  downlinked  altitude.  The 
downlinked  altitude  will  be  right  justified  in  the  data  field  of  the  Status  List.  The 
status  field  will  show  “HC”  (e.g.,  TWA515  240  340/nC”). 

The  Data  Link  eligible  receiving  controller  with  track  control  may  respond  by 
contacting  the  flight  deck  via  voice  radio.  The  error  displays  may  be  cleared  by 
entering  the  FLID,  deleting  the  IC  Status  List  entry  (DL  F3  “IC“  and  the  FLID  (R 
position  only)  or  “DE  IC”  and  the  FLID,  or  by  updating  the  aircraft's  assigned  or 
interim  altitude. 


B-17 


Initial  Contact  Evaluation 

Please  record  your  comments  and  recommendations  here. 
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Part  V 


Predefined  Controller  Messages  (PDM) 
(Menu  Text) 


-  Function 

The  PDM  or  Menu  Text  function  permits  the  controller  to  uplink  nonsafety 
critical  messages  by  selecting  them  from  a  predefined  menu  list.  Menus  can  be 
tailored  to  meet  the  specific  requirements  of  individual  airspace  sectors. 

-  Menu  Format 

The  menu  is  a  Host  situation  display  tabular  list  identified  by  "ML”  in  the  upper 
left  comer  of  the  list.  Each  line  of  the  menu  contains  one  message  preceded  by 
an  identifying  menu  referent  used  to  select  the  message.  The  menu  referent 
must  begin  with  an  alphabetic  character.  Up  to  ten  messages  can  be  displayed  in 
the  menu  list.  A  sample  menu  is  shown  below: 


A 

WRI ILS  OUT  RWY  6  /  24 

B 

BAD  WEATHER  WARN 

MIC 

CHECK  STUCK  MIC 

CALL 

CALL  COMPANY 

-  Inputs  to  Send  a  Menu  Text  Message 

To  send  a  menu  text  message,  type  DL  F9  (or  “UM”),  the  menu  item  referent, 
and  the  FLID  (e.g.  DL  F9  “A  USA456”).  Messages  cannot  be  sent  using  a 
trackball  designation  of  the  item  in  the  menu  text  list. 

The  message  can  be  sent  to  all  aircraft  that  are  Data  Link  eligible  for  the  sector 
by  substituting  “  *ALL  ”  for  the  FLID. 

-  Full  Data  Block  and  Status  List  Displays  on  Menu  Text  Uplink 

When  a  menu  text  message  is  uplinked,  an  up-arrow  ( T  )  symbol  replaces  the 
hourglass  in  the  first  position  of  the  first  line  of  the  Full  Data  Block  at  all 
positions  displaying  the  Full  Data  Block.  The  up-arrow  is  removed  when  the 
system  receives  the  appropriate  positive  or  negative  response  from  the  flight 
deck,  when  it  is  deleted  from  the  Status  List,  or  if  an  FAI  or  ERR  indication  is 
returned. 
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For  all  messages  sent  from  the  menu,  the  Status  List  will  display  the  AID 
followed  by  the  menu  item  identifier,  and  the  current  status  of  the  transaction 
(e.g.,  "AA231  CALL  SNT").  The  Status  List  line  is  deleted  when  the  appropriate 
positive  response  from  the  flight  deck  is  received,  or  when  it  is  deleted  from  the 
Status  List. 

When  a  message  is  sent  to  all  aircraft,  a  single  line  is  created  in  the  Status  List 
with  “ALL”  appearing  the  FLID  field.  The  status  line  is  deleted  when  all  of  the 
aircraft  respond  with  the  appropriate  positive  response.  A  separate  line  is 
created  in  the  Status  List  for  each  negative  aircraft  response  to  an  all  message,  or 
if  a  transmission  error  occurs  (“ERR”,  “FAI”). 

-  Deleting  Menu  Text  Transactions 

The  controller  can  close  the  transaction  and  delete  "UNB",“ERR”,  “FAI”,  or 
“NEG”  indicators  by  typing  DL  F3“ MT”  and  the  FLID  (R  position)  or  “DE  MT” 
and  the  FLID  (D  position).  If  the  controller  chooses  to  delete  a  transaction  in  the 
“SNT”  or  “TIM”  states,  “/OK”  must  be  included  in  the  command  sequence  prior  to 
“TC”  (e.g.  DL  F3“  /OK  MT  USA219”).  The  transaction  can  also  be  deleted  by 
eliminating  the  “MT”  and  FLID  in  the  command  and  using  the  trackball  to  select 
the  dot  preceding  the  appropriate  line  in  the  Status  List.  If  the  trackball  is  not 
used  for  this  command,  all  MT  transactions  for  the  aircraft  that  are  not  in  the 
SNT  or  TIM  state  will  be  deleted  from  the  Status  list. 

-  Controlling  Menu  Text  List  Content 

A  menu  build  function  will  be  used  by  supervisory  personnel  to  create  sector- 
tailored  menus.  However,  the  controller  will  have  the  capability  to  determine 
whether  the  menu  list  will  be  displayed,  and  to  selectively  display  or  suppress 
individual  items. 

The  menu  list  can  be  suppressed  by  typing  DS  F2  “OFF”.  The  list  is  retrieved  to 
the  situation  display  by  typing  DS  F2  ”ON”.  These  entries  cannot  be  made  from 
the  D  position. 

Suppression  of  the  individual  messages  in  the  menu  is  accomplished  by  typing 
DS  F3,  the  menu  item  referent,  and  “OFF”  (R  position  only)  or  “MS”,  the  menu 
referent,  and  “OFF”.  A  message  can  be  retrieved  by  substituting  “ON”  in  the 
command  sequence. 
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Up  to  five  messages  can  be  suppressed  or  retrieved  in  a  single  command  by 
separating  the  menu  referents  with  spaces. 


-  Inputs  to  Move  the  Menu 

The  menu  text  list  can  be  moved  to  any  position  on  the  situation  display  by  using 
the  trackball  to  SELECT  the  header  area  of  the  list  and  pressing  the  trackball 
ENTER  to  indicate  the  list’s  new  position. 


B-21 


Menu  Text  Evaluation 


Please  record  your  comments  and  recommendations  here. 
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Part  VI 


Altimeter  Setting  (ASM) 

-  Function 

This  Data  Link  message  uplinks  an  altimeter  setting  to  the  flight  deck.  Normally, 
the  uplink  will  be  accomplished  automatically  in  accordance  with  procedures  and 
directives.  An  altimeter  setting  can  also  be  manually  uplinked  by  the  controller. 

-  Manual  Uplink  of  Altimeter  Setting 

An  altimeter  setting  can  be  manually  uplinked  by  the  R  position  by  typing  QD 
(QAK),  the  designator  for  the  station  providing  the  local  altimeter  setting,  “S” 
and  the  FLID.  The  entry  for  the  D  position  substitutes  “QD”  for  the  QAK  entry. 

-  Full  Data  Block  and  Status  List  Displays  for  Altimeter  Setting  Messages 

When  an  altimeter  setting  message  is  uplinked  either  automatically  or  manually, 
an  up-arrow  (  T  )  symbol  replaces  the  hourglass  in  the  first  position  of  the  first 
line  of  the  Full  Data  Block  at  all  positions  displaying  the  Full  Data  Block.  The  up- 
arrow  is  removed  when  the  system  receives  a  “ROG”  or  “UNB”,  or  is  deleted  from 
the  Status  List. 

For  all  altimeter  messages,  the  Status  List  will  display  the  AID  followed  by  the 
station  designator  and  the  altimeter  setting,  and  the  current  status  of  the 
transaction  (e.g.,  “AAL231  DCA2997  SNT”).  The  Status  List  line  is  deleted 
when  a  “ROG”  is  received.  Messages  in  any  other  transaction  state  must  be 
manually  deleted. 

-  Deleting  Altimeter  Setting  Transactions 

The  controller  can  close  the  transaction  and  delete  "UNB",  "TIM”,  “FAI”  or  “ERR” 
indicators  by  typing  DL  F3“ AS”  and  the  FLID  (R  position)  or  “DE  AS”  and  the 
FLID  (D  position).  If  the  controller  chooses  to  delete  a  transaction  in  the  “SNT” 
or  “TIM”  states,  “/OK”  must  be  included  in  the  command  sequence  prior  to  “IC” 
(e.g.,  DL  F3“/ OK  AS  USA219”).  The  transaction  can  also  be  deleted  by 
eliminating  the  “AS”  and  FLID  in  the  command  and  using  the  trackball  to  select 
the  line  in  the  Status  List.  If  the  trackball  is  not  used  for  this  command,  all  ASM 
transactions  for  the  aircraft  that  are  not  in  the  SNT  or  TIM  state  will  be  deleted 
from  the  Status  list. 
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Altimeter  Setting  Evaluation 
Please  record  your  comments  and  recommendations  here. 
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GENERAL  QUESTIONS 


1.  Do  the  Full  Data  Block  symbols  for  Data  Link  equipage  and  eligibility  (open 
diamond  and  “hourglass)  appear  to  conflict  with  other  symbols  in  DSR? 


2.  Do  the  transaction  status  abbreviations  used  in  the  Status  List  appear  to 
conflict  with  other  abbreviations  in  DSR? 


3.  Does  the  design  provide  an  adequate  capability  to  filter  the  contents  of  the 
Status  List  (i.e.,  by  message  type  and  status)? 


4.  In  future  builds,  would  inclusion  of  category  keys  on  the  keyboard  and  in  the 
D-CRD  be  useful  if  a  D  position  controller  is  involved  in  sending  Data  Link 
messages? 
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5.  In  future  builds,  would  a  “repeater”  of  the  Status  List  at  the  DSR 
D  position  display  be  desirable? 


6.  In  the  current  design,  the  active  transfer  of  communication  mode 
(AUTO/MANUAL)  can  be  determined  by  pressing  the  DS  key  and 
checking  the  mode  in  the  R-CRD.  In  future  builds,  would  a  transfer  of 
communication  mode  indicator  that  is  present  continuously  on  the 
situation  display  be  desirable? 


7.  In  future  builds,  do  you  feel  that  it  will  be  useful  to  take  advantage  of 
the  DSR’s  color  capability  to  emphasize  important  information  and 
warnings  (e.g.,  color  coding  of  unable  responses,  failures  and  timeouts  in 
the  Status  List)? 


8.  Earlier  CPDLC  studies  indicated  that  controllers  would  prefer  the 
the  Full  Data  Block  indicators  for  equipage  and  eligibility  be 
changed  from  the  open  diamond  and  “hourglass”  to  an  open  diamond 
(equipped  but  not  eligible)  and  a  filled  diamond  (equipped  and 
eligible).  Do  you  agree  with  this  recommendation? 
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